STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL95.LZH/letters_fj/text0022.txt

Text File | 1995-10-04 | 8.6 KB | 199 lines

Hi again,

> OK OK. BAD MOOD.

OK, we'll stick with that from now on then. I wrote an article in one of
the threads in c.s.a.programmer yesterday calling it simply MOOD, but I
did say that it was temporary and subject to change.

> >I think we should set up some kind of mailing list to make the discussions
...
> Well, I think there are some standard programs to manage this. The problem
> would be to get a specific email address for it, cause here we depend on a
> common RS6000 and don't have our own site. So we need authorizations.

That`s no problem at all. I`m the only one with root priviliges on the
Sparc20 I use at work and I also have root access on the Indigo2 in one
of my collegues office.  :-)

> I think you already have a few email addresses. Could you get one more for
> the list? There should be a unix account with it, so we can set up the

Simple enough to do.

> program that will manage the list. I could look for the programs, if you
> want me to.

I found the programs I needed at the Linux68k WWW site. I've compiled it
while writing this and will try to get it running soon.

> >Anything special you could recommend? I'm out of books at the moment.
> Yes, if you've never read it, try John Fante. Really very great realistic stuff.
> Also, I like Boris Vian a lot, but I don't know what it looks like once

Never heard of either of those, what kind of stuff is it (apart from being
realistic)?

> translated: it relies so much on the style and the language.

Ah, yes that's always a problem. I've not read anything in Swedish for
several years since the translations (especially for mainstream things like
thriller and fantasy) are so unbelievably bad. I could do better in my sleep.

> Try Alexandre Dumas' Count of Monte Cristo. Great adventure stuff. The kind
> of books you're supposed to read when you're 14. But I still like it a lot.

I've read those and all the Jule Verne books. As you say, they're very good.
I hardly think Monte Cristo was written for 14 year olds, but I guess you're
right in saying that most people do read those books around then.
I just remembered that I've never read 'The three musceteers' in an uncut
edition, though, which could be just what I'm looking for.

> Then, there is Stefan Sweig's twenty four hours in the life of a woman.
> Celine's travel to the end of the night (these are all approximative
> translations of the titles in french...)

Meaning that it could be quite difficult to find them here, I guess.

> I'm giving you title of some of the books I read recently. I'll take a look
> in my library and make you a top twenty or something like that.

Thanks very much.

> fight. And you're supposed to speak french when fencing. Official language.

Fortunately there doesn't seem to be much to say when you fight with the
epee.  ;-)
Everything is handled by the electronics.

> I don't know how it's called in english. I did the "fleuret" in the

That's what the English call foil. In Swedish it's 'florett', which is
pronounced almost exactly like the French word (not that I know any French).

> beginning. Very precise stuff. Then I switched to "sabre" (the weapon with
> which you touch with the edge). This weapon is a lot more savage and

Yes, I've read about that. Sounds interesting, but I don't know if they
teach that at the club I've joined. It also has the same 'strange' rules
as the foil.

> aggressive. Never really tried the third one ("epee"). The way you can touch
> any part of the body seemed very confusing to me.

I think that's one of the great advantages of the epee. None of those
'strange' rules deciding who may attack and when and the scoring is much
simpler to handle.

> I have no clue yet, but will try to understand this. I have to get a doom 1
> wad home to use it on the falcon. I only have doom 2 here. BTW, would it be
> very difficult to make dview work with doom 2 wads?

I have no idea. I can't believe there can be that many changes between the
WAD file formats, but I've not seen any documentation.

> OK. This is what I thought: as you're drawing (well, I believe) the ssectors
> more or less front to back, and walls in doom have just three parts, the
> transparent one being the middle one (correct?), couldn't you keep track

Well, the middle part is not handled as a wall at all, but simply as the
empty space that it really is. There are only two kinds of walls:
- Wall covering everything from floor to ceiling.
- Wall consisting of a top and/or a bottom, not necessarily with space in
  between.

> for each column in the screen, of the highest pixel drawn from the bottom
> and of the lowest from the top? I mean, all the walls and sprites contained

Yes, that is was DVIEW is doing to keep track of where it can draw the walls
behind. The checking of that is also what's causing the errors I've been
talking about when the tops lowest level goes below the bottoms highest.
It _should_ not be difficult to fix those errors...

> I'll try to be clearer: You draw (clipped) the current ssector. If there are
> transparent segments, you recurse to the corresponding ssectors. When this
> is done, you draw the sprites contained in the ssector (clipped by our
> column table). Then, and only then, you update the column table (which means
> you have to keep a local table for the currents ssector, I believe).
> Does this seems feasible to you?

Hmm, it might be possible to do something like that. We'll need to keep
the coordinate data, though.  :-(

> Ah, but I've just thought about something... The problem is that you'd have
> to stack column tables because of the sprites which have to be drawn back to
> front.

Ah, yes there's perhaps that problem if you do it the way you described,
but if we're going to keep all the coordinate stuff we could probably draw
and clip all the sprites at the end anyway. I still don't believe we'll be
able to keep all that in the DSP ram, though, but I hope I'm wrong.

> I have to think a little more about it. Perhaps there's a way, still.
> I don't know. Perhaps all this is just crap. I have to understand Dview
> better, first, I believe.

You seem to be getting a pretty good idea of it.

> Perhaps it could be managed by keeping a permanent and global column table,
> updated each time you draw an opaque segment. And when you recurse to a new
> ssector, you just give it the coordinates of the quadrilateral polygon that
> must clip it. With both the clipping polygon and the column table, there
> should be no problem, even with the sprites. Of course, some sprites would
> be drawn in several parts.
> Is this clear? Any question?
> Does this seem efficient to you?
> Of course, this is perhaps stupid, because it is theory.

I'm not sure I understand why you intend to clip by the original (transparent)
'wall' polygon. I guess it would be easier to discuss these things after
you've taken a good look at DVIEW so that we can relate everything to what
is happening there. It's rather difficult to describe this sort of thing
only with text.

By the way, DOOM itself is supposed to draw the sprites at the very end IIRC.

> >need all the pixel coordinate info to do the sprites right as well...
> Impractical. There must be a "right moment" to draw the sprites without
> bothering about all this.

Hopefully.

> >> draw. And do the transparent textures bring problems?
> >I've not really considered those yet. Are they really that common in DOOM?
> Not exactly common, but they definitely exist. In fact, in the first level
...
> curious to know how doom handles this. But they should be no problem.

Yes, if they really are not too common it probably won't matter much if
we handle them in a slighty different way.

> What I call a transparent wall can be the boundary between two ssectors, not
> always corrseponding to a transparent texture or even to a real wall. So
> they are very common.

OK, but you only need to skip those. That's already done in DVIEW. It's the
walls with textures with holes in them that must be handled separately.

> It really seems like the algorithm has to be strongly restrained by the fact
> that there will be sprites.

Or at least it'll have to keep around data that could be thrown away otherwise.

> >It would even be enough to clear the screen before you start drawin, but
> >that might be slower.
> Yes it will. But in dview, don't you do this already (if you xor, you must

There would be no need to unless the XOR is really used (I believe I only
do it in single step mode, but it has been a while since I wrote the code).

Regards,
Johan

--
  Chalmers University   | Why are these |  e-mail:   [e-mail]
     of Technology      |  .signatures  |            [e-mail]
                        | so hard to do |  www/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)